1. Technical Field
This invention relates generally to processing data in a computer system. More particularly, the invention relates to optimizing code execution in a compare sequence. Still more particularly, the present invention relates to a means for reducing the number of instructions executed to find a successful compare in code sequence comprised compare statements.
2. Description of Related Art
In general, optimizing code in the past has consisted of compilers examining code that has been generated on a first pass and improving the generated assembler code by eliminating code which cannot be reached during execution, eliminating redundant register load instructions, consolidating like sequences of code, and generally fine-tuning the code-generated on the first pass. All of this code optimization takes place independently of the use that is made of the code when it is shipped to customers. The experienced practitioner would recognize that the process of application development goes through recognized phases, generally including code development, code test, code capture, and product shipment to customers. After an application is shipped, very little further optimization is possible, since compiler optimization options are decided in the code development phase. (One of ordinary skill in the art would also recognize that the phases of application development are the same whether employed by a recognized industry manufacturer or in-house by a customer who, in essence, is shipping the product to himself.) After the code is shipped, further optimization is very limited regardless of the differences among users of the code.
For example, consider the following users for an application shipped to two different customers for the same Insurance Application. FIG. 1 depicts a screen shot of a typical application menu as used for data entry into the application. Screen one of the application consists of a standard menu presenting the user with a requirement to select or enter the type of insurance, in this case for a claim. The choices presented to the customer in FIG. 1 are: Auto, Home, Life, Property, and Travel. Customer A, xe2x80x9cAcme Travel,xe2x80x9d enters xe2x80x9cTravel.xe2x80x9d Most modern menu driven applications would save xe2x80x9cTravelxe2x80x9d and provide a form of keystroke optimization filling in xe2x80x9cTravelxe2x80x9d for Customer A the next time screen one is displayed. Similarly, Customer B, xe2x80x9cPrecious Protection for Your Jewelry,xe2x80x9d enters xe2x80x9cProperty,xe2x80x9d so xe2x80x9cPropertyxe2x80x9d is filled in the next time Customer B causes screen one to be displayed.
FIG. 2A illustrate compiler level statements like COBOL which would process code to handle the input field for screen one in FIG. 1 Although both customers might be happy with the saved keystrokes on subsequent uses of the screen one menu, an examination in FIG. 2A of the assembler code generated by COBOL, C, or any other compiler underlying the identification of the Type of Insurance Claim, presents glaring inefficiencies.
FIG. 2B illustrates assembler language code created by processing the compiler level statements in FIG. 2A.
The creator of screen one for this insurance application had no knowledge of what type of insurance processing would be used by the purchaser. Likewise, the purchaser has no knowledge of the order in which the creator coded the compares in the compiler level language. Due to copyright and liability issues, application purchasers seldom have access to the source code for an application, and the compiler has no opportunity to optimize or tailor the generated assembler code to perform compares in the order best suited to each individual customer.
Therefore, in actuality, Customer A has purchased code which always executes four unnecessary compares before getting a TRUE condition on xe2x80x9cTravelxe2x80x9d; while Customer B has purchased code which always performs three unnecessary compares before getting a TRUE condition on xe2x80x9cProperty.xe2x80x9d It is TRUE that some customers xe2x80x9cluck out,xe2x80x9d and their order of processing happens to match the order specified by the creator of the code.
This simplified example of five possible LEGAL VALUES on one screen menu is similar to compare code sequences permeating all software. It is a fairly safe assumption that an IF statement will generate a compare of two character strings 50 percent of the time, and that most compound IF statements or IF THEN ELSE statements will generate a list of compares. Since the IF statement is the foundation of software logic, these compares are by no means limited to code which supports screen menu input. Indeed, menus represent only the tip of the iceberg. Most business applications access lists of customers, accounts, part numbers, billing histories, and all the paraphernalia of the business world.
One of ordinary skill in the art would recognize that the compares cannot be avoided because the possibility of a changed input field, including a field in error, must be tested for on each and every transaction. Therefore, a need exists to provide a means of optimizing assembler code for individual users and customers by modifying code sequences based on actual customer usage.
In general, there is a need to optimize the code generated by nearly every compiler used by industry. For example, some compilers in both the C language and the COBOL language allow the user to specify a level of code optimization desired by the user. Almost all compiler providers recognize the need to allow the customer to optimize compilers for either optimal execution speed or minimal storage use. Although large scale applications and some systems programs provide a list of parameters which may generally affect storage and execution characteristics, these parameters are generally of a global nature, which are not effective at the individual code sequence level.
What is needed is a means for modifying individual code sequences in such a way as to optimize their execution by reducing the instructions needed for unnecessary compares.
The present invention discloses a method and apparatus for optimizing code execution by reducing the number of instructions executed to find a successful compare. A compare sequence is executed at least once, and the results of that execution are used to modify the compare sequence for a subsequent execution of the compare sequence. In a preferred embodiment, the compare sequence is modified by placing the TRUE compare statement, determined by the previous execution, at the beginning of the compare sequence. In another preferred embodiment, the compare sequence is re-ordered in descending order of the number of TRUE compares associated with each compare statement. The compare sequence may be immediately modified after each successful compare or the customer may define external sampling periods for modification of the compare sequences. The modification may be a single program modification of compare structures for delayed modification or a global modification of programs for delayed modification.